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A METHOD OF AUTOMATICALLY ANALYSING THE STRUCTURE OF A 
SOFTWARE SYSTEM 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

This invention relates to a method of automatically analysing the structure of a software 
system, such as an operating system for a computing device. 

2. Description of the Prior Art 

When trying to gain a high-level view of the inter-dependencies between the many 
executables (perhaps 500 or- more) in an operating system, the view manually arrived at 
even by a skilled analyst quickly gets obscured by the sheer number of relationships. 
Hence, it is very difficult to identify inappropriate coupling between components of the 
OS (e.g. a component where one of its executables depends on a high-level other 
component for no good reason, indicating perhaps bad layering or inappropriate 
inclusion of an executable in the component). 

. Further, it is very helpful to be able to calculate the order in which executables and 
groups of strongly inter-dependent executables (e.g. components) should be built to 
ensure that executables with the least number of dependenceis are built first. But this is 
again difficult, even for the skilled analyst, and can take several days. Performing regular 
(e.g. daily or weekly) re-calculations as an OS build progresses is therefore impractical 
when relying on a highly skilled, but essentially manual process. 



Glossary 



Term 


Description^ 


Dependency 


An executable is said to depend on another executable if it calls one 
or more of the exported functions in the other executable. 


Executable or 
executable file 


Generic term used to specify either a DLL or EXE, containing binary 
code directly runnable by the computer. A DLL provides exported 
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functions for use by other executables. An RTTR is a self-contained 
program and generally provides a single entry point. 


Exported 
functions 


The set of functions provided by a DLL that may be called by other 
executables. 



WO 2004/111841 



PCT/GB2004/002475 



3 

SUMMARY OF THE INVENTION 

The invention automatically produces a structural analysis of a software system's 
executables, separated into levels based on the concept of 'dependency depth'. 

Given a simple list of executables* dependencies, a tool that implements the invention 
automatically produces a dependency table sorted by 'dependency depth' level, with the 
least dependent executables listed at the bottom and with the most dependent at the top. 
Executables with circular dependencies are not problematic, with the executables 
involved automatically being treated as being at the same level as each other. 

The tool achieves this by assigning a unique and well-defined 'dependency depth' 
number to each executable. This number defines how many levels exist in the 
executable's dependency tree. This number may be calculated by expanding that 
executable's dependency tree recursively so that each executable is listed in expanded 
form exactly once in the tree for the right-most occurrence only, and is listed in collapsed 
form for all other occurrences. This guarantees that the tree is as deep as possible and is 
therefore also unique, making it usable for sorting a set of executables according to their 
dependency depth numbers. 

Using the table that is produced in this way simplifies the production of a block diagram 
based on dependency, with executables at the same dependency level grouped together 
horizontally in the block diagram. Hence, the present invention provides a mechanism 
that organises the executables in a rational and repeatable manner that clarifies the high- 
level view of the inter-dependencies between the many executables. It can also be used to 
decide the order in which executables need to be built where the least dependent 
executable is built first 

With further information giving the grouping of executables into components, the same 
technique may be used to find the dependency depth number of a component, where a 
component is a group of related executables which have strong inter-dependencies, 
usually built and deployed as a- unit. Component M depends on component N if any 
executable in M calls a function of any executable in N. 
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Summary of the benefits of the present invention 

• Better understanding of OS interdependencies through a systematic, reliable and 
5 comprehensive analysis of the system architecture. A system architect can find 

inappropriate coupling between components of the OS — e.g. a component where 
one of its executables depends on a high-level other component for no good reason, 
indicating perhaps bad layering or inappropriate inclusion of an executable in the 
component; 

10 

• Enables automatic, rapid and reliable calculation of the order in which components 
should be built. Items at low levels are guaranteed to be buildable without 
previously building items at higher levels. Circular dependencies need to be built 
together; 

15 

• Results of the analysis can be used by other tools; 

• Leads to improved modularity, aiding rollout of independent features; 
20 • Helps produce a block diagram of the OS. 



t 
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DETAILED DESCRIPTION 

To simplify this description, we will use specific examples of very simple hypothetical 
Operating Systems that have only a small number of executables. 

If executable A calls a function in executable B and another function in executable C, A 
is said to depend directly on both B and C. This can be represented by the following line: 
A:BC 

where the executable on the left of the colon depends directly on the executables on the 
right 

Example 1: No circular dependencies 

The following table specifies the complete direct dependency structure of a hypothetical 
OS with six executables, A, B, C, D, E and F: 

A:BC 

B:C 

C: 

D; A C E 
E: A 
F:E 

Using this direct dependency structure, a dependency tree can be generated for each 
executable which includes direct dependencies as well as their dependencies and so on 
recursively, as shown in Figure 1: 

In these representations of the dependency trees, a direct dependency is indented by one 
tab to the right of the executable that depends on it, so as before: 

1 . E depends directly on A only 

2. D depends directly on A, C and E 

3. A depends directly on B and C 

4. B depends direcdy on C only 

5. C depends on nothing. 
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This can be simplified by collapsing sub-trees that are repeated in the tree, giving the 
following trees, where a M- * indicates a collapsed executable sub-tree, expanded further to 
the right somewhere else in the tree, as shown in Figure 2: 

5 Collapsing repeats is important for the tool's memory and speed efficiency when 
analysing a real OS, with potentially thousands of executables and millions of repeated 
sub-trees within each tree. See an algorithm for achieving this efficiendy below. 

. Each executable can then be assigned a unique dependency depth number by counting the 
10 levels of indentation, given by the maximum number of dots in any row for the specified 
executable's tree above. 
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The dependency depth number can now be used to partition the OS into levels with 
15 executables having the lowest dependency depth number at the bottom as follows 

Level 4: D, F 

Level 3: E 
Level.2: A 
20 Level 1: B 
Level 0: C 

Example 2: Includes circular dependencies 

The following table specifies the complete direct dependency structure of a second 
25 hypothetical OS: 
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A:BC 
B:C 
C: A 

5 Using this direct dependency structure, the dependency trees are represented as follows — 
where recursion stops on reaching a circular dependency to avoid infinite regress, as 
shown in Figure 3: 

Again the unique dependency depth number is found by counting the levels of indentation, 
10 given by the maximum number of dots in any row above. 
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Partitioning the OS into levels again using these dependency depths produces the 
following: 

15 

Level 3: 

A,B,C 

Note that the circular dependencies cause empty levels 0, 1 and 2. 

20 

Efficient algorithm for collapsing repeated sub-trees 

A real OS has potentially thousands of executables and millions of repeated sub-trees 
within each tree, so an algorithm for collapsing repeats efficiently and in an easily 
searchable and parseable way, is very important for a workable tool. 

25 

As described below, the finally generated tree for D from example 1 above can be stored 
efficiendy as a single easily computer-searchable and parseable string as follows: 
D's tree = 1 A+ C+ E:l { A:2{ B:3{ C:4{}C }B C+ }A }E 1 
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The format of a collapsed executable Y is simply *Y+ * 

The format of an executable Z that has a circular dependency on it is e Z+ (circular) * 
The start tag for executable X's expansion at indentation level L is 

<X:L {' 
and its end tag is 

'}X' 

and between the braces are the details for the executables X depends on which is empty 
for an executable with no dependencies. 



To build e.g. D's tree from example 1, named D-tree here for convenience, follow these 
steps, noting that substrings enclosed by angle brackets represent variable quantities: 

1. Initialise D-tree to empty string 

2. For each executable used by D (i.e. for X=A, X=C and X=E) do the expansion in ' 
15 step 3 at level L=l 

3. Add used executableX at level L: 

a) If X equals D, add 'X+ (circular) ' and finished step 3 for X 

b) Search for previously added partial expansion *X:M {'in D-tree with no terminating 
'}X' and if found, signifies a partially built expansion and therefore a circular 

20 dependency, so add 'X+ (circular) ' 

c) Search for previous expansion *X:M {<anyText>}X * in D-tree where M is a 
previously added level number 

d) If found and L is less than or equal to M, add ' X:L-P and finished step 3 for X 

• e) If found and L is greater than M, replace previously added 
25 <X:M {<anyText>}X' by *XM+' 

f) Now add the expansion 

i. Add X:L { e marking expansion start for X 

ii. Add expansion for each executable used by X at level L+l (i.e. repeat step 3 
for all executables used by X recursively) 

30 iii. Add '}X f marking expansion end for X 
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Npte that at step 3f) above the previously found expansion from step 3a) above can't be 
used for further efficiency, because that expansion will include executables that 
themselves are expanded to a different level than required in step 3f) above. 

5 Here is the full tree expansion for the OS described in example 1: 
A=> , B:1{C:2{}C}B C+ ' 
B=> 'CrlOC 1 
C => 1 1 

D=>'A+ C+ E:1{A:2{B:3{C:4{}C}B C+ }A }E ' 
10 E=> , A:1{B:2{C:3{}C}B C+}A' 

F => *E:l { A:2{ B:3{ C:4{}C }B C+ }A }E ' 

And here is the expansion for the OS described in example 2: 
A => *B:1 { C:2{ A+(circular) }C }B C+' , 
15 B=> f C:l{A:2{B+(ckcular) C+(circular) }A }C 

C => 'A:l{ B:2{ C+(circular) }B C+(circular) }A f 

The maximum nvimber in this string gives the dependency depth for the executable when 
it is followed by an empty expansion '{}\ When not followed by an empty expansion, 
20 adding 1 to the maximum number in the string gives the dependency depth, handling the 
case of a circular dependency at the deepest level in the tree. 



25 



Symbian OS v7.0s with more than 550 executables produces a full definition of this kind 
that has size 81 OK. 



